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channel (26) for exchanging information exclusively with the telecommunication device (14, 18) is established. A mode for transmitting 
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A DATALINK PROTOCOL FOR A 
TELECOMMUNICATIONS METHOD AND SYSTEM 



Rented Application 
This application claims the benefit of U.S. Provisional Application, Serial No. 
60/106,1 16 filed October 29, 1998. 

Firi H of the Invention 
5 This invention relates to telecommunications systems and methods. More 

particularly, the invention relates to real-time telecommunications systems and methods 
that use a datalink protocol to provide various messaging services. 

Back ground of the Invention 
With the advent of protocols for sending packetized data over networks, many 
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have endeavored to send packetized voice signals over network infrastructure. The 
challenge has been to transmit packetized voice signals with reliability and quality 
equal to that attained by traditional switch-based telephone systems at a cost- 
competitive price. 

5 Because voice signals require real-time transmission, the general view has been 

that voice communications must have a "guaranteed" bandwidth channel, as in 
traditional switch-based telephone systems, in order to provide the desired quality of 
service. This view has spawned protocols (e.g., Asynchronous Transfer Mode (ATM) 
and IsoEthernet) that provide virtual, dedicated channels for voice and other real-time 
10 applications and a separate virtual data channel. Networks that implement these 
protocols are expensive. These high costs have stunted the growth of the installed 
base of these products. An affordable and dominant network protocol is standard 
(IEEE 802.3) lOBaseT Ethernet, which does not provide a virtual guaranteed 
bandwidth channel. The large installed base of 10 Mbit Ethernet has created an 
15 incentive for the development of improved Ethernet protocols, such as 100 Mbit, 1 
Gbit, and switched Ethernet. 

For years, the telecommunications industry has sought to use a data network 
infrastructure to carry voice (or audio) signals. For one, telephony, messaging, and 
computer integration are generally less expensive and less complicated over a single 
20 network infrastructure than over separate infrastructures. By sending voice over the 
data network, the functionality of advanced telephone systems can merge with the 
power, scalability and open connectivity of networking solutions. 

Sending packetized voice over the same network infrastructure as packetized 

2 
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data eliminates the need for two infrastructures and takes advantage of advanced 
computer telephony and personal computer messaging applications running on the data 
network without the expense of hardware and software links. Another well-known 
advantage of packetized voice is the ability to transfer signals over wide area network 
5 infrastructures (e.g., the Internet) as a means of saving on toll charges for telephone 
usage. Accordingly, various products have been introduced to send packetized voice - 
over the Internet. Some of these products include accessories that interface with the 
Private Branch Exchange (PBX) to enable time-division multiplexed digital signals to 
be converted into packet-based digital signals. 
10 The advantages of sending voice and data over the same infrastructure have 

been recognized for some time. Several entities have contemplated telecommunication 
systems that operate both voice and data communications over one network 
infrastructure (i.e., one wire for both voice and data). The challenge is to provide 
quality service for voice and other applications that need real-time bandwidth even 
1 5 when a network is heavily loaded with data traffic, and to do so in a cost-effective 
manner. 

Summary 

The invention features a method for communicating with a telecommunication 
device over a network. A mode for transmitting data onto the network to the 
20 telecommunication device is selected from one of a reliable transmission mode, an 
unreliable transmission mode, or a prioritized unreliable transmission mode. A packet 
is formed comprising the data to be transmitted to the telecommunication device and 

3 
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indicia representing the selected transmission mode. The packet is transmitted onto 
the network using the selected transmission mode. 

For the reliable transmission mode and, optionally, the semi-reliable 
transmission mode, a communication channel for exchanging information exclusively 

5 with the telecommunication device is established. The communication channel can be 
established by transmitting an initial packet to the telecommunication device and 
providing indicia in the initial packet representing the communication channel. 
Subsequent packet communication is coordinated with the telecommunication device 
by using the indicia to generate a sequence number for the packet. 

10 At the telecommunication device, an expected packet number is generated from 

the indicia. The expected packet number is compared to the sequence number in the 
packet. An acknowledgment is issued when the sequence number in the packet 
matches the expected packet sequence number. The packet can be re-transmitted each 
time a predetermined period of time elapses until (i) the acknowledgment associated 

15 with the packet is received from the telecommunication device or (ii) the packet is 
resent a maximum number of times. A second packet can be transmitted to the 
telecommunication device after the acknowledgment associated with the first packet is 
received from the telecommunication device. For the reliable transmission mode, a 
limit to the number of packets transmitted and unacknowledged by the 

20 telecommunication device is determined. 

For the prioritized unreliable transmission mode, the packet is queued for 
transmission to the telecommunication device ahead in order of non-prioritized 
packets. The prioritized unreliable transmission mode can be selected when the data in 

4 
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the packet are time-critical data, such as, for example, audio data and video data. 
Accordingly, data that are time-sensitive in nature, such as audio data, can receive 
preferential treatment for transmission onto the network. 

In another aspect, the invention features a telecommunications device for 

5 communicating over a network with a receiving telecommunications device. The 
telecommunication device comprises a processor that selects a mode for transmitting .. 
data from one of a reliable transmission mode, an unreliable transmission mode, or a 
prioritized unreliable transmission mode. A packet generator forms a packet 
comprising the data to be transmitted to the receiving telecommunication device and 

1 0 indicia representing the transmission mode selected by the processor. A transmitter 
transmits the packet received from the packet generator onto the network using the 
selected transmission mode. The network can be an Ethernet network. For the 
reliable transmission mode and, optionally, the semi-reliable transmission mode, the 
telecommunication device includes a communication channel that is established for 

1 5 exchanging information exclusively with the receiving telecommunication device. The 
communication channel can be a unidirectional communication channel through which 
packets of data flow exclusively to the receiving telecommunication device and 
through which acknowledgments flow exclusively from the receiving 
telecommunication device. 



20 Description of the Drawings 

The invention is pointed out with particularity in the appended claims. The 
above and further advantages of the invention may be better understood by referring to 
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the following description in conjunction with the accompanying drawings, in which: 
Fig. 1 shows an exemplary telecommunication system comprising a sending 
telecommunication device in communication with a receiving telecommunication 

device over a network; 
5 Fig. 2 shows an exemplary functional block diagram of the telecommunication 

devices; 

Fig. 3 shows an embodiment of a portion a protocol stack used to practice the 
invention; 

Fig. 4 shows an exemplary format for packets transmitted over the network 
10 according to the protocol of the invention; 

Fig. 5 shows an exemplary process of establishing a communication channel 
between the sending device and the receiving device; and 

Fig. 6 shows the sending and the receiving devices communicating using the 
reliable transmission mode. 

15 Detailed Description 

Fig. 1 shows an exemplary packet-based telecommunication system 10 
incorporating the principles of the invention. The system 10 includes a sending 
telecommunication device 14 in communication with a receiving telecommunication 
device 18 via a network 22. The network 22 can be, for example, a local-area network 
20 (LAN) or a wide area network (WAN), an Intranet or the Internet. In one 
embodiment, the network 22 is an Ethernet network. 

For simplicity of illustration two telecommunication devices 14, 18 are shown, 
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although the system 10 can include many additional telecommunication devices. 
Examples of telecommunication devices 14, 18 include a telephone set and a telephone 
line interface module(TLIM) unit. The TLIM unit can connect to the central office of 
a telephone service provider via the public switched telephone network (PSTN) and 
5 can include any number of TUMs for continuing expansion of the system 10. Each 
telecommunication device 14, 18 can have an Ethernet hub for connecting that device 
to a network interface card of a computer system (not shown). Accordingly, 
telecommunication devices and computer systems use the same network infrastructure. 
Communication between the telecommunication devices 14, 18 over the 
10 network 22 is accomplished using a packet-based protocol. The protocol of the 
invention provides a variety of messaging services (or transmission modes) for 
exchanging packets between the telecommunication devices 14, 18. The messaging 
services, described further below, include: (i) a reliable transmission mode, (ii) an 
unreliable transmission mode, (iii) a prioritized unreliable transmission mode, and (iv) a 
1 5 semi-reliable transmission mode. 

Generally, the sending device 14 selects one of the transmission modes for 
transmitting data to the receiving device 18. For the reliable and, optionally, the semi- 
reliable transmission modes, the telecommunication devices 14, 18 establish a point-to- 
point communication channel 26 for exchanging information exclusively with each 
20 other. The communication channel 26 supports one source and one destination. In 
one embodiment, the communication channel 26 is unidirectional, i.e., packets 
containing data (Le., data packets) flow exclusively from the sending device 14 to the 
receiving device 18 and for the reliable transmission mode acknowledgment packets 

7 



SUBSTITUTE SHEET (RULE 26) 



WO 00/27076 PCTAJS99/25353 

flow exclusively from the receiving device 18 to the sending device 14. In another 
embodiment, the communication channel 26 is bidirectional, wherein each 
telecommunication device 14, 18 is at the same time a source and a destination of data 
and acknowledgment packets. 

5 The sending device 14 forms a packet comprising the data to be transmitted to 

the receiving telecommunication device 1 8. The packet includes indicia representing - 
the selected transmission mode. The sending device 14 transmits the packet onto the 
network 22 using the selected transmission mode. In transit, the transmitted packet 
can pass through one or more devices (not shown) connected to the network 22 that 

10 route the packet to the receiving device 18. 

While communicating with the receiving device 18 in one of the transmission 
modes, the sending device 14 can concurrently engage in communication with another 
telecommunication device on the network 22 using any one of the transmission modes. 
For example, the sending device 14 can be communicating with the receiving device 1 8 

15 in the reliable transmission mode while communicating with another 

telecommunication device in the prioritized unreliable mode. Communication with the 
receiving device 18 by the sending device 14 can also occur concurrently using more 
than one of the transmission modes. For example, the sending device 14 can be 
exchanging some packets with the receiving device 18 using the reliable transmission 

20 mode amidst packets exchanged using the unreliable transmission mode. Further the 
sending device 14 can establish multiple concurrently active channels of 
communication with the receiving device 18. 

Fig. 2 shows an exemplary functional block diagram of the telecommunication 

8 
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devices 14, 18. Each telecommunication device 14, 18 includes a packet controller 30 
coupled to a physical network interface 40, memory 42, and an I/O subsystem 50. The 
memory 36 can be implemented using synchronous dynamic random access memory 
(SDRAM). Other types of memory devices can be used (e.g., SRAM). 
5 They physical network interface 40 includes a transmitter 34 and a receiver 3 8 

for transmitting and receiving packets over the network 22. The physical network 
interface 40 also includes a buffer 46 for queuing a packet next in line for transmission 
onto the network 22. The buffer 46 can hold one or more packets at a time for 
transmission by the transmitter 34 onto the network. In one embodiment, the physical 
10 interface 40 is a Media Access Control device (MAC) operating as a 10/100 Ethernet 
port capable of a 100 Mpbs network data rate. 

The I/O subsystem 50 includes I/O devices such as, for example, a telephone 
keypad, a telephone handset, a headset, a microphone, or a speaker. The I/O 
subsystem 50 can receive input signals through the telephone keypad or audio signals 
15 through the microphone or handset, and can transmit signals to the speaker or the 
handset. For the purposes of converting analog signals to digital, and digital signals to 
analog, the I/O subsystem 50 includes codecs (not shown). The packet controller 30 is 
in electrical communication with the I/O subsystem 50 to form packets from the signals 
received from the I/O devices. The packet controller 30 also controls the transfer of 
20 packets between the memory 42 and the physical network interface 40. 

Fig. 3 shows a portion of a protocol stack 52 used by each device 14, 18 of the 
system 10. The protocol stack portion 52 includes a physical layer 54, a data link layer 
58, an optional network layer 62, e.g., Internet Protocol (IP), and a transport layer 66. 
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The data link layer 58 of the invention can interface either the network layer 62 or the 
transport protocol 66. 

At the sending device 14, upon accepting a packet from a higher layer (e.g., the 
transport layer 66 or network layer 62), the data link layer 58 encapsulates the packet 
5 by adding a header and a trailer to the packet, and then sends the encapsulated packet 
to the physical layer 54 for transmission onto the network 22. At receiving device 18, 
upon receiving an encapsulated packet from across the network 22, the physical layer 
54 passes the encapsulated packet up to the data link layer 54. The data link layer 54 
then examines and removes the header information from the encapsulated packet, and 
10 passes the remainder of the packet to the higher layers of the protocol stack 52. 

Fig. 4 shows an exemplary general format 78 for packets transmitted over the 
network 22 according the principles of the invention. Packets can include other 
information beyond what is described below or have a different order of fields and still 
be within the scope of the invention. The format 78 includes an Ethernet header 82 
1 5 having a destination MAC address field, a source MAC address field, and an 

encapsulation mode field 84. The destination and source MAC addresses are unique 
six-byte addresses given to each device connected to the network 22. For example, in 
the Ethernet header 82 of a packet transmitted from the sending device 14 to the 
receiving device 18, the source MAC address is the unique MAC address of the 
20 sending device 14, and the destination MAC address is the unique MAC address of the 
receiving device 18. 

The encapsulation mode field 84 of the Ethernet header 82 identifies the 
encapsulation mode employed to encapsulate information within packets exchanged 
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between the sending 14 and the receiving 1 8 devices. In one embodiment, the 
encapsulation mode field 84 identifies one of three modes of packet header 
encapsulation: (1) the data link protocol of the invention, (2) 802.1p/Q IEEE standard, 
or (3) the IP protocol. If the encapsulation mode field 84 indicates that the 
5 encapsulation mode is the IP protocol, then the protocol field 88 of the encapsulation 
header 86 indicates that there is a second encapsulation header field 87, which in one . 
embodiment is a UDP header. In this embodiment, the Ethernet encapsulation mode 
field 84 specifies the first encapsulation header 86 as an IP (Internet Protocol) header, 
and the protocol field 88 within the IP header specifies UDP (User Datagram Protocol) 
1 0 as the second encapsulation header type 87. Similarly, each encapsulation header 
specifies the subsequent encapsulated header type. Accordingly, the packet format 78 
accommodates he layering of protocols. 

If the encapsulation mode field 84 identifies either the 802.1p/Q or the IP/UDP 
mode, the Ethernet header 82 is followed by an encapsulation header 86. For either 
15 type of encapsulation mode, 802. lp/Q and IP/UDP protocols, the encapsulation header 
86 includes a sub-header field 88 that can be used to activate the data link control 
protocol of the invention. For example, the encapsulation mode field 84 of the 
Ethernet header 82 can identify the 802.1p/Q header, and the sub-header field 88 of the 
subsequent encapsulation header 86 can identify the data link control protocol of the 
20 invention. In this example, the data link control protocol of the invention operates in 
conjunction with the 802. lp/Q header. In other embodiments, the data link control 
protocol of the invention can operate in conjunction with the IP/UDP protocols or 
independently of either the 802. lp/Q or IP/UDP protocols. 

11 
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If either the encapsulation mode field 84 of the Ethernet header 82 or the sub- 
header field 88 of the encapsulation header 86 indicates that the packet is to be 
transmitted according to the data link control protocol, the format 78 of the packet 
also includes a packet type field 89. Such packet type field 89 identifies the type of 

5 contents in the packet. Because each transmission mode is associated with one of the 
packet types, as described below, the packet type field 89 also correlates to the 
transmission mode for that packet. In one embodiment, each packet type is associated 
with a unique two-byte value. Each packet transmitted between the 
telecommunication devices 14, 18 includes one of these unique values in the packet 

10 type field 89 to indicate the data link control packet type. The various packet types 
transmitted between the telecommunication devices 14, 18 include: 



a SYN packet, which is a control packet issued by the sending device 



14 to establish a communication channel; 



15 



a SYN_ACK packet, which is an acknowledgment packet issued by the 
receiving device 18 in response to a SYN packet from the sending 



device 14; 



a REL_DATA packet, which is a data packet issued by the sending 



20 



device 14 using the reliable transmission mode; 

a RELjVCK packet, which is an acknowledgment packet issued by the 

receiving device 18 in response to receiving a valid RELJDATA data 



packet from the sending device 14; 



an UNRDATA packet, which is a data packet issued by the sending 



device 14 using the unreliable transmission mode; 
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an AUD_DATA packet, which is a data packet issued by the sending 
device 14, containing audio data and indicia of a priority status for 
placing the data packet onto the network 22; 
t a SEM_DATA packet, which is a data packet issued by the sending 
5 device 14 using the semi-reliable transmission mode; 

• an ERROR packet, which is a control packet issued by the sending or - 

receiving devices 14, 18 indicating that an error has occurred in the 
network 22; 

a FIN packet, which is a control packet issued by the sending device 14 
10 to close the communication channel 26; and 

• a FIN_ACK packet, which is an acknowledgment packet issued by the 
receiving device 18 in response to receiving the FIN control packet 
from the sending device 14. 

When the packet type is a SYN, SYNACK, TJNRJDATA, RELDATA 
15 SEMJDATA REL ACK, ERROR, FIN, or FIN_ACK packet, the packet format 78 
also includes a data link control header 90. The data link control header 90, when 
used, includes a sequence number and virtual device identifiers (VDNs). The sequence 
number is used to initialize the communication channel 26 and to coordinate 
communications between the telecommunication devices 14, 18 as described below. 
20 During initialization, a VDN is assigned to each logical device supported at a MAC 
address. Each MAC address can support up to 2 A 16 internally mapped physical or 
logical devices. 

When the packet type is a SYNACK, AUDJDATA UNR_DATA 
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REL J3ATA, SEMJ5ATA, or ERROR packet, the packet format 78 also includes a 
data portion 94 that includes the data related to that particular communication. For 
example, for an AUD_DATA packet, the relevant data include audio data generated or 
forwarded by the sending device 14. For a SYN_ACK packet, for example, the 
5 relevant data can include channel status, such as "channel already established" or "new 
session created." 

Establishing the Communication Channel 

The system 10 uses two packet types to establish the communication channel 26 
between the telecommunication devices 14, 18 when operating according to the 
10 reliable and, optionally, the semi-reliable transmission modes. One packet type is the 
SYN packet, issued by the sending device 14; the other is the SYN_ACK packet, 
issued by the receiving device 18 in response to the SYN packet from the sending 
device 14. 

To open the communication channel 26, the receiving device 18 needs to 
15 receive a SYN packet from the sending device 14. When a packet arrives, the packet 
controller 30 of the receiving device 18 examines the packet type in the packet type 
field 89 to determine the packet type. If the packet type differs from a SYN packet, 
and the telecommunication devices 14, 18 have not yet established a communication 
channel, the receiving device 18 sends an ERROR packet to the sending device 14 
20 indicating that no communication channel exists. 

Fig. 5 shows an exemplary process of establishing the communication channel 
26. As shown, the telecommunication devices 14, 188 can establish the 
communication channel 26 with two packet transmissions in approximately the time 

14 
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expended by a packet making one round-trip. Generally, upon power up or reset or 
the initiation of a new channel indicated by an intention to send a semi-reliable or 
reliable packet to a new destination, the sending device 14 automatically initiates the 
process of establishing the communication channel 26 by sending the SYN packet to 

5 the receiving device 18 (step 102). The data link control header 90 of the SYN packet 
includes a sequence number used by the devices 14, 1 8 to uniquely represent the 
communication channel 26 and to initialize packet numbering for subsequent packet 
transmissions. The sending device 14 stores the sequence number, referred to as 
LastSequenceNumber, in a variable data structure. 

10 The sending device 14 can randomly generate the sequence number. In one 

embodiment, the randomly generated number is a 16-bit non-zero value. The 
generated sequence number should differ from a sequence number, if any, used to 
represent a previous communication channel established between the sending and 
receiving devices 14, 18. 

15 The response to the SYN packet by the receiving device 18 depends, in part, 

on the current communication status between the devices 14, 18. When the sending 
and receiving devices 14, 18 are not currently communicating via an active 
communication channel, the receiving device 18 generates at least two numerical 
values from the sequence number in the SYN packet. One value represents the 

20 communication channel that is being established between the sending and receiving 
devices 14, 18. This value is stored in a data structured referenced as ThisChannel. A 
second value represents the sequence number that the receiving device 18 expects to 
find in the next data packet received from the sending device 18. This value is stored 

15 
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in a variable data structure referenced as NextPacketToReceive. The following 
exemplary pseudo-code illustrates the process: 
ThisChannel = LastSequenceNumber, 

NextPacketToReceive - (LastSequenceNumber + IncrementalValue); 
5 where IncrementalValue is any positive or negative non-zero value. To keep both 
values, ThisChannel and NextPacketToReceive, within a predetermined range, the 
above process steps can use a modulo operation as follows: 

ThisChannel = LastSequenceNumbei%SequenceRange; 
NextPacketToReceive = (LastSequenceNumber + IncrementalValue) 
10 %SequenceRange; 

where SequenceRange is a large predetermined constant (e.g., 2 A 16). 

The receiving device 18 returns a SYNACK packet to the sending device 14 
(step 106). The SYN_ACK packet includes a sequence number that is the same as the 
sequence number in the SYN packet. By this acknowledgment, the receiving device 
15 18 indicates to the sending device 14 that the receiving device 18 has received the 
SYN packet identified by the returned sequence number and is available to receive 
packets. The SYNjVCK packet can include indicia in the data portion 94 of the 
packet indicating that the communication channel has been established. When the 
sending device 14 determines that the returned sequence number matches the sequence 
20 number in the SYN packet, the sending device 14 releases the SYN packet from the 
buffer 46 and can commence transmitting data packets to the receiving device 18. 

If instead the devices 14, 18 have already established a communication channel 
when the receiving device 1 8 receives the SYN packet, the receiving device 1 8 

16 
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compares the sequence number in the SYN packet with the value ThisChannel. When 
the values match, the receiving device 1 8 returns a SYN^ACK packet with indicia in 
the data portion 94 that the communication channel has already been established. This 
situation may occur when an earlier SYNACK issued by the receiving device 1 8 is 

5 lost during transmission, and the sending device 14 resends the SYN packet after 
waiting a predetermined period for the response. If instead the values differ, the 
receiving device 1 8 replies with a SYN_ACK packet indicating that a new 
communication channel has been established. The receiving device 18 generates 
ThisChannel and NextPacketToReceive as described above. The sending and 

10 receiving devices 14, 18 communicate using this new communication channel, and not 
with the previously established communication channel. 
Reliable Transmission Mode 

In general, communication on the network 22 is unreliable in that packets can 
be lost, duplicated, delayed, or reordered during transmissioa An advantage of the 

1 5 reliable transmission mode is that this mode can convert an unreliable telephone 

communication path into a reliable communication channel. In the reliable transmission 
mode, the receiving device 18 receives packets in sequential order and processes each 
packet only once. In one embodiment, the sending device 14 awaits the return of an 
acknowledgment from the receiving device 18 before transmitting the next packet. 

20 Other embodiments can employ windowing schemes with transmit windows larger than 
one packet. 

Fig. 6 shows the sending and the receiving devices 14, 18 communicating using 
the reliable transmission mode. As described in Fig. 5, the devices 14, 18 establish a 

17 



SUBSTITUTE SHEET (RULE 26) 



WO 00/27076 PCT/US99/2S353 

communication channel (steps 102 and 106). To generate a RELJDATA data packet, 
the sending device 14 obtains the data for the data portion 96 of the packet, 
encapsulates the data portion 96 with the Ethernet and other header information as 
described above, generates a new sequence number, and places the new sequence 
5 number in the data link control header 90. The new sequence number equals the 
LastSequenceNumber incremented by the IncrementalValue. The sending device 14 .. 
then increments the LastSequenceNumber by the IncrementalValue. 

In step 1 10, the sending device 14 transmits the REL DATA packet containing 
the new sequence number to the receiving device 18. If the new packet sequence 
10 number does not match the NextPacketToReceive value, the receiving device 18 
ignores the REL.DATA packet. If instead these values match, the receiving device 18 
accepts the data in the data portion 96 of the packet, passing the data to the higher 
levels of the protocol stack 52, and replies with a REL_ACK packet (step 1 14). The 
REL_ACK packet includes a return sequence number that matches the sequence 
1 5 number in the REL_D ATA packet. 

If instead the RELJDATA packet is a duplicate of a REL_DATA packet 
previously received by the receiving device 18, then the sequence number of that 
duplicate packet is different from the NextPacketToReceive value by the 
IncrementalValue. In this event, the receiving device 18 returns a REL_ACK packet 
20 having the same sequence number as the duplicate packet, but ignores the data in the 
REL_DATA packet. 

If the sequence number in the received RELJDATA packet is neither the 
NextPacketToReceive value nor differs from the NextPacketToReceive value by the 
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IncrementalValue, the receiving device 18 ignores the REL_DATA packet and 
accompanying data, and does not return the REL_ACK acknowledgment packet. The 
receiving device 18 deems the RELDATA packet to be an out-of-order packet. 

As illustrated by steps 118 and 122, and again by steps 130, 134 and 138, when 
5 the sending device 14 does not receive a proper REL_ACK packet within a 
predetermined time-out period, which can change based upon the number of retry 
attempts, the sending device 14 retransmits the REL_DATA packet. If the number of 
time-outs and subsequent retries exceeds a predetermined limit, the sending device 14 
signals an error to the higher layers of the protocol stack 52. When the sending device 
10 14 receives a REL_ACK for which the sending device 14 is not waiting, the 
acknowledgment is ignored (step 145). 

When the sending device 14 receives a REL_ACK packet, the sending device 
14 compares the returned sequence number in the REL_ACK packet with the 
LastSequenceNumber to determine whether the acknowledgment packet corresponds 
15 to the currently unacknowledged REL DAT A 

In one embodiment, only one REL_DATA can remain unacknowledged at any 
one time for the communication channel 26. The sending device 14 maintains a 
variable data structure, referenced as OutstandingUnackPackets, which keeps count of 
the number of transmitted and unacknowledged data packets. The sending device 14 
20 sets the value of OutstandingUnackPackets to one after transmitting the RELJDATA 
packet to the receiving device 18. Upon receiving the REL_ACK packet, the sending 
device 14 compares the returned sequence number in the REL_ACK packet with the 
LastSequenceNumber. If the values match, then the sending device 14 resets the value 
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of OutstandingUnackPackets to equal zero. Accordingly, the sending device 14 
releases the buffer 46 for the next packet to be transmitted. 

If instead the returned sequence number matches the sequence number of a 
RELJDATA packet transmitted immediately prior to the currently transmitted 
5 REL DATA packet, the sending device 14 ignores and discards the REL ACK 
packet. If the returned sequence number matches neither the LastSequenceNumber . 
nor the sequence number of the immediately prior REL_DATA packet, the sending 
device 14 re-transmits the currently transmitted RELJDATA packet. In this regard, 
the sending device 14 operates as if a time out occurred while awaiting the REL_ACK 

10 packet. 

Unreliable Transmission Mo de 

For the unreliable transmission mode, an established communication channel 
between the sending and receiving devices is unnecessary, nor does the sending device 
14 require acknowledgments from the receiving device 18 before transmitting the next 

15 packet. In the unreliable transmission mode, the sending device 14 forms a 

UNRDATA data packet by setting the packet type to indicate unreliable transmission. 
Transmission of the UNR_DATA packets is continuous; the buffer 46 is released 
immediately for transmission of the next packet after the transmitter 34 places the 
packet in the buffer 46 onto the network 22. 

20 Prioritized Unreliable Transm ission Mode 

Like the unreliable transmission mode described above, the sending device 14 
requires no acknowledgments from the receiving device 18 before transmitting the next 
packet when the packet is using the prioritized unreliable transmission mode. Also, an 
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established communication channel between the sending and receiving devices is not 
required. The prioritized unreliable transmission mode increases the likelihood the 
data packets are successfully transmitted onto the network 22. The sending system 14 
can designate priority for a data packet by inserting the unique value associated with 

5 the AUD_DATA packet type into the packet type field 89 of the packet format 78. 

Data packets given a priority receive preferential treatment from the sending - 
device 14 over non-prioritized packets (e.g., RELJDATA and UNR_DATA) for 
placement onto the network 22. For example, the sending device 14 can be currently 
forwarding a REL_DATA packet onto the network 22, and waiting the return of an 

10 acknowledgment, when a AUD_DATA packet is produced. The sending device 14 
can remove the RELJDATA packet from the buffer 46 and insert the AUD_D ATA 
packet in the buffer. In one embodiment, the preempted RELJDATA packet is 
discarded. In another embodiment, the REL JJATA packet is stored until after the 
sending device 14 completely places the AUD_DATA packet on the network 22. 

1 5 Then the transmission of the preempted RELJDATA can be resumed. 

The prioritized unreliable transmission mode can be useful for transmitting 
packets containing time-sensitive information such as a voice (or audio) data and video 
data. (Audio data are time-sensitive because as time elapses the usefulness of the 
audio data decreases significantly.) Consequently, audio data can be given, in effect, a 

20 separate path to ensure that such data reaches the network 22 and, consequently, the 
target destination while the audio data are still useful. 
Semi-Reliable Transmission Mode 

The semi-reliable transmission mode is a hybrid of the reliable transmission 
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mode and the unreliable transmission mode. In one embodiment, like the reliable 
transmission mode, the semi-reliable transmission mode establishes a communication 
channel between the sending and receiving devices so that the devices can exchange 
information exclusively with each other. In another embodiment, this communication 
5 channel need not be established. Like the unreliable transmission mode, the sending 
device 14 may, under conditions described below, transmit a packet to the receiving - 
device 18 without having received an anticipated acknowledgment for a previously 
transmitted semi-reliable packet. 

The sending system 14 can designate a data packet for semi-reliable 
10 transmission by inserting the unique value associated with the SEMJDATA packet 
type into the packet type field 89. After the sending device 14 transmits an 
SEM_DATA packet onto the network 22, the sending device 14 waits a 
predetermined period of time for return of a corresponding acknowledgment. During 
that predetermined period of time, the sending device 14 may retransmit the packet. If 
1 5 the acknowledgment returns within that period, the sending device 14 prepares and 
sends the next packet onto the network 22. However, if that period of time elapses 
without receiving the acknowledgment, the sending device 14 removes the 
SEM_D ATA packet from the buffer 46 and transmits the next packet onto the 
network 22. 
20 Closing the Channel Connection 

The sending device 14 can close the communication channel 26 by issuing a 
FIN packet. The sending system 14 can designate a packet as a FIN packet by 
inserting the unique value associated with the FIN packet type into the packet type 
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field 89. The FIN packet also includes a value representing the currently established 
communication channel that the sending device 14 is attempting to close. 

In response to the FIN packet, the receiving device 1 8 issues a FIN_ACK 
packet. The FINACK packet includes a return value matching the value obtained 
5 from the FIN packet. The sending device 14 compares the returned value in the 
FIN_ACK packet with the value sent in the FIN packet. A match closes the 
communication channel 26. To resume communication with the receiving device 18, 
the sending device 14 must issue SYN packet. 

If the sending device 18 does not receive the FINACK within a predetermined 
10 period of time, the sending device re-transmits the FIN packet. After a maximum 
number of attempts, the sending device signals an error to the higher layers of the 
network architecture. 

While the invention has been shown and described with reference to specific 
preferred embodiments, it should be understood by those skilled in the art that various 
15 changes in form and detail may be made therein without departing from the spirit and 
scope of the invention as defined by the following claims. 
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1 . A method for communicating with a telecommunication device over a 
network, the method comprising the steps of: 

selecting a mode for transmitting data to the telecommunication device from 
one of a reliable transmission mode, an unreliable transmission mode, or a prioritized - 
5 unreliable transmission mode; 

forming a packet comprising the data to be transmitted to the 
telecommunication device and indicia representing the selected transmission mode; and 

transmitting the packet onto the network using the selected transmission mode. 

2. The method of claim 1 further comprising the step of establishing a 
communication channel for exchanging information exclusively with the 
telecommunication device. 

3. The method of claim 2 selecting the reliable transmission mode and wherein 
the packet is a first packet and the step of establishing the communication channel 
comprises the steps of: 

transmitting an initial packet representing the communication channel; and 
5 coordinating subsequent packet communication with the telecommunication 

device by using the indicia to generate a sequence number for the first packet. 

4. The method of claim 1 selecting the reliable transmission mode and further 
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comprising the step of resending the packet each time a predetermined period of time 
elapses until (i) an acknowledgment associated with the packet is received from the 
telecommunication device or (ii) the packet is resent a maximum number of times. 

5. The method of claim 1 selecting the reliable transmission mode and wherein 
the packet is a first packet and further comprising the step of transmitting a second 
packet to the telecommunication device after an acknowledgment associated with the 
first packet is received from the telecommunication device. 

6. The method claim 5 further comprising the steps of: 
generating an expected packet number from the indicia; 
receiving the first packet at the telecommunication device; 

comparing the expected packet number with the sequence number in the first packet; 
5 and 

issuing an acknowledgment when the sequence number in the first packet 
matches the expected packet sequence number. 

7. The method of claim 1 selecting the reliable transmission mode and further 
comprising the step of receiving an acknowledgment from the telecommunication 
device in response to the transmitted packet. 

8. The method of claim 7 further comprising the steps of: 
providing a sequence number in the packet; and 
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providing a second sequence number in the acknowledgment that corresponds 
to the sequence number in the packet. 

9. The method of claim 1 selecting the prioritized unreliable transmission mode 
and further comprising the step of queuing the packet for transmission to the 
telecommunication device ahead in order of non-prioritized packets. 

10. The method of claim 1 selecting the prioritized unreliable transmission 
mode when the data are time-sensitive data. 

1 1 . The method of claim 1 wherein the telecommunication device is a first 
telecommunication device and further comprising the step of establishing a first 
communication channel with the first telecommunication device and a second 
communication channel with a second telecommunication device connected to the 

5 network, wherein the second communication channel is concurrently active with the 
first communication channel. 

12. The method of claim 1 1 wherein the first and second telecommunication 
devices are the same telecommunication device. 

13 . The method of claim 1 selecting the reliable transmission mode and further 
comprising the step of determining a limit for a number of packets transmitted to and 
unacknowledged by the telecommunication device. 
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14. The method of claim 13 further comprising the step of changing the limit 
from the determined number while the communication channel is active. 



15. A method for communicating with a telecommunication device over a 
network, the method comprising the steps of: 

selecting a mode for transmitting data to the telecommunication device from 
one of a reliable transmission mode, an unreliable transmission mode, a prioritized 
5 unreliable transmission mode, or a semi-reliable transmission mode; 

forming a packet comprising the data to be transmitted to the 
telecommunication device and indicia representing the selected transmission mode; and 

transmitting the packet onto the network using the selected transmission mode. 



16. A telecommunication device for communicating over a network with a 
receiving telecommunications device, comprising: 

a processor selecting a mode for transmitting data to the receiving 
telecommunication device from one of a reliable transmission mode, an unreliable 
5 transmission mode, or a prioritized unreliable transmission mode; 

a packet generator forming a packet comprising the data to be transmitted to 
the receiving telecommunication device and indicia representing the transmission mode 
selected by the processor; and 

a transmitter transmitting the packet received from the packet generator onto 
10 the network using the selected transmission mode. 



27 



SUBSTITUTE SHEET (RULE 26) 



WO 00/27076 PCTAJS99/2S353 

1 7. The telecommunications device of claim 1 6 wherein the network is an 
Ethernet network. 



18. The telecommunications device of claim 16 further comprising a 
communication channel established exclusively between the telecommunication 
devices, wherein the communication channel is a unidirectional communication channel- 
through which packets of data flow exclusively to the receiving telecommunication 

5 device. 

19. The telecommunications device of claim 16 further comprising a 
communication channel established exclusively between the telecommunication 
devices, wherein the communication channel is a unidirectional communication channel 
through which acknowledgments flow exclusively from the receiving 

5 telecommunication device. 

20. The telecommunications device of claim 16 further comprising a 
communication channel established exclusively between the telecommunication device, 
wherein the communication channel is a bidirectional communication channel through 
which data is exchanged in both directions between the sending and receiving devices. 

21 . In a telecommunications network including a receiving telecommunication 
device and a sending telecommunication device, a protocol for communicating 
between the sending and receiving telecommunication devices comprising: 
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computer-executable services transmitting data using one of a reliable 
5 transmission mode, an unreliable transmission mode, a prioritized unreliable 
transmission mode; and 

computer-executable operations that form a packet comprising the data to be 
transmitted to the receiving telecommunication device and indicia representing the 
selected transmission mode. 

22. The protocol of claim 21 further comprising computer-executable 
operations that establish a communication channel for exchanging information 
exclusively with the receiving telecommunication device. 

23. The protocol of claim 21 wherein the computer executable operations that 
form the packet are implemented at a data link layer. 
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